03. Overview

Governance, Risk, and Compliance is often used as an umbrella term for activities within an organization that operate to support business operations and goals as they related to governing specific activities, managing risk, and complying with different types of business obligations. While that umbrella term is broader than the specific Security GRC components that are focused on throughout this course, it's important to understand how overall GRC has taken shape.

While businesses have long since been attempting to operate with specific goals in mind, GRC, as a practice, has taken shape over the past 30 years or so. Two major factors in the rise of GRC relate to fraud and business failure occurring near the turn of the century.

Fraud and business failure as drivers to GRC make a great deal of sense. If you look back over history, major events have driven regulatory response in some way. The failures of the Great Depression led to the formation of both the Security Exchange Committee and the Federal Deposit Insurance Corporation (FDIC) in an attempt to keep individuals’ financial assets safe from poorly managed market and investment activities. There are other examples as well, like the 1864 formation of the Office of the Comptroller of Currency, which slightly preceded the end of the Civil War and ended what was known as the Free Banking Era --- a period of loosely constructed bank regulations.

If you fast-forward to the late 1990s and early 2000s we start to see significant corporate fraud and failure with the dotcom bubble bursting, all culminating with the bankruptcy of Enron. Enron was an American energy commodity and service company who filed bankruptcy on December 3, 2001, after it was revealed that their financial statements and outlook were the result of systemic corporate fraud. These events led directly to the passage of the Sarbanes-Oxley Act in 2002, which held executives at publicly traded companies liable for the accuracy of financial statements.

At the same time, there are schools of thought starting to develop around how organizations should be managed in order to protect their employees, shareholders, and the public. The OCEG or Open Compliance and Ethics Group was one of the leaders in developing a systematic approach to ensuring that organizations were running responsibly and in 2002 they developed a GRC operating model which defined GRC as “the integrated collection of capabilities that enable an organization to reliably achieve objectives, address uncertainty and act with integrity.” The idea being that the business process can be managed in such a way that we are able to ensure the business is operating in a manner consistent with some of the goals we defined earlier:

• Mission Oriented
• Shrewd
• Trustworthy

The only challenge as it relates to Security GRC is that business processes and Security / Cybersecurity processes aren’t necessarily managed in the same way. It's difficult to think about applying the same process used to audit financial statements to those used to audit the effectiveness of a security control or equating customer retention activities to managing vulnerabilities. As a result, we have traditionally thought about GRC in two ways:

1. Operational
2. IT --- with Security GRC being a large part of IT GRC.

There is one caveat, however, in more modern GRC implementations, folks do talk about how IT infrastructure has become such an embedded part of business processes that it's nearly impossible to separate business from IT operations. Think about certain business risks, for instance. Many of them may be tied to technology failure. Carrying that forward, we also talk about how security is impossible to separate from IT Operations because of the reliance on security mechanisms to ensure that our IT infrastructure is operating effectively. So, there is a school of thought that the term GRC can now be broadly applied to both business or operational GRC and IT GRC. Throughout the rest of this course, however, we’ll treat the two separately and focus on IT GRC and specifically on the security components contained within it.